在前幾天，我陸續完成了 AI 避雷探針的網站部署、會員登入、歷史報告以及 PDF 下載等功能。
原本覺得主要功能都已經完成，接下來只要進行最後的測試與優化就可以了。

但今天在進行完整測試時，我發現了一個之前沒有注意到的問題：
明明已經有會員帳號，換一台裝置登入後，歷史報告卻沒有出現！
這讓我開始思考，會員登入和歷史報告到底是怎麼連接的？為什麼在原本的裝置可以看到資料，換一台裝置卻不行？
今天就來記錄這次的測試過程，以及我準備如何排查這個問題。

一、這次測試的目的

在之前的開發過程中，我已經陸續完成以下功能：

• 店家搜尋與評論取得
• Gemini AI 分析
• AI 避雷報告顯示
• 會員登入
• 歷史報告儲存與查看
• 歷史報告更新
• 報告列印與 PDF 儲存
• Firebase Hosting 部署

但之前的測試大多是在同一台電腦、同一個瀏覽器中進行。
這次我想從一般使用者的角度重新測試，確認網站是不是真的可以在不同裝置上使用。
因此，我使用原本的會員帳號，在另一台裝置上登入，接著前往歷史報告頁面。
沒想到，原本預期會出現的報告紀錄並沒有顯示出來。
【實際測試 1：原本裝置的歷史報告頁面】

【實際測試 2：另一台裝置登入後的歷史報告頁面】

二、為什麼有會員帳號，卻看不到歷史報告？

一開始看到這個結果時，我想到的第一件事就是：
「既然登入的是同一個帳號，為什麼歷史報告沒有一起出現？」
但仔細想想，會員登入成功，不代表歷史報告一定有正確儲存。
這其實涉及兩個不同的功能。

1. 會員登入

會員登入主要負責確認使用者的身分。
例如，使用者透過 Firebase Authentication 登入後，系統就可以取得目前登入會員的識別資訊。

2. 歷史報告儲存

歷史報告則需要另外將分析結果儲存到資料庫，並且在會員查看歷史紀錄時，再從資料庫讀取對應的資料。
所以即使會員可以正常登入，如果報告沒有成功寫入資料庫，或讀取歷史紀錄時沒有取得正確的資料，還是可能出現空白的情況。

三、開始排查可能的問題

為了找出原因，我會先從以下幾個方向檢查。

1. 確認報告是否真的有儲存

首先，要確認在原本裝置產生的報告，是否真的有成功寫入 Firestore。
不能只因為歷史報告頁面看得到資料，就直接認定資料一定存在雲端。
我會到 Firebase Console 的 Firestore Database 查看相關集合與文件，確認報告是否真的存在。
如果資料根本沒有寫入 Firestore，就需要回頭檢查儲存報告的程式。

2. 確認報告有沒有綁定會員身分

接著，檢查每一筆歷史報告是否有記錄對應的會員 UID。
例如，假設會員登入後取得的 UID 是某個識別值，那麼儲存報告時，就應該將這個 UID 一起記錄。
之後讀取歷史報告時，再依照目前登入會員的 UID 查詢資料。
這樣才能確保不同會員只會看到自己的報告，也能讓同一個會員在不同裝置上取得相同的歷史紀錄。

3. 檢查歷史報告頁面的讀取方式

另一個需要確認的地方，是歷史報告頁面到底從哪裡取得資料。
如果目前的程式只從瀏覽器的 localStorage 讀取歷史紀錄，那麼資料通常只存在該瀏覽器的本機環境。
換到另一台裝置後，即使登入同一個會員帳號，也不會自動取得原本裝置的 localStorage 內容。
但如果已經使用 Firestore 儲存資料，就要進一步確認歷史報告頁面是否真的從 Firestore 讀取，而不是仍然使用本機資料。

四、localStorage 和 Firestore 有什麼不同？

這次的問題也讓我重新整理了兩種資料儲存方式的差異。

這裡也要特別注意：Firestore 並不是只要啟用就會自動同步所有資料。
程式仍然需要正確地將報告寫入 Firestore，並在讀取時查詢正確的會員資料，同時設定適當的安全規則。
因此，這次不能只檢查登入功能，還需要確認儲存和讀取流程是否完整。

五、我希望完成的修正方向

釐清問題後，發現我是存在localStorage，接下來的目標是讓歷史報告真正與會員帳號連結。
預期的流程應該是：

1. 使用者登入會員帳號。
2. 系統取得目前登入會員的 UID。
3. 使用者完成店家評論分析。
4. 系統將報告內容及會員 UID 儲存到 Firestore。
5. 使用者在另一台裝置登入相同帳號。
6. 歷史報告頁面從 Firestore 讀取該會員的報告。
7. 使用者可以查看過去的分析紀錄。

這樣才算完成跨裝置的歷史報告功能。
另外，Firestore 的安全規則也很重要。不能只靠前端篩選 UID，就認為資料已經受到保護；還需要在資料庫端限制使用者只能讀取或修改自己有權限存取的資料。

六、今天的心得

今天原本只是想進行網站的完整測試，沒想到卻發現歷史報告無法在不同裝置之間正常顯示。
這讓我理解到，登入功能、資料儲存和資料讀取其實是不同的環節。
以前開發時，只要在原本的電腦上看得到報告，就很容易認為功能已經完成。
但從使用者的角度來看，會員登入後應該能在不同裝置上取得自己的歷史紀錄，才算符合預期。
這次也提醒我，開發網站不能只測試功能有沒有出現，還要確認資料究竟儲存在哪裡、如何讀取，以及不同會員之間的資料是否有正確區隔。
接下來，我會繼續確認 Firestore 的資料寫入與讀取流程，讓 AI 避雷探針的歷史報告功能更加完整。
網站能夠登入只是第一步，讓資料正確保存、隨時讀取，而且不會被其他會員看到，才是完整的會員系統。